Graphically constructed control and scheduling system

ABSTRACT

A system and method for controlling a model train system and for defining a finite state machine for implementing control of the system. A computer (32) that is running a graphic user operating system is coupled through its serial port to a master control unit (MCU) (48). The MCU is coupled to slave control units (SCUs) (50, 52) and to a hand control unit (HCU)(152) through a token ring network (69) over which the computer transmits commands to energize selected track sections and to control the speed of locomotives (88, 90) running thereon. The MCU and SCUs are coupled to the sections of tracks and to electromagnetic switches (42, 44, 46) that determine the route of the trains over the sections of track. Furthermore, detector circuits (126) monitor a detector pulse to sense the presence of a locomotive or train on a particular section of track, producing an indicative output signal that is provided to the computer. The user graphically defines events, conditions, and control actions that are to be carried out on a visually displayed schedule manager grid. In addition, the user can graphically define a control panel that includes graphic controls, which can be manipulated by the user to establish the speed of a locomotive and to control the status of the electromagnetic switches. The control system can also be applied to control other systems that include electrically energized components.

FIELD OF THE INVENTION

This invention generally pertains to a method and apparatus forcontrolling and scheduling the operation of a plurality of devices usinga computer, and more specifically, for defining a control scheme for aplurality of devices, which in one preferred form of the invention isused for controlling and scheduling the operation of toy vehiclesrunning on a track.

BACKGROUND OF THE INVENTION

In the traditional control paradigm, the occurrence of an event triggersa control action. The event may be, for example, a signal whosemagnitude exceeds a predefined level, or the lapse of a predefined timeinterval. The control action can be almost anything that comprises anappropriate response to the event. For systems that include a verydefined set of events and corresponding responses, a hardwiredelectromechanical control may be entirely adequate to accomplish thedesired task. As the complexity of the controlled system increases,logic circuits offer a significant advantage over simpleelectromechanical controls.

However, if the system to be controlled is less well defined or issubject to frequent changes, a more generalized control is required thatcan easily be adapted to variations in the events, conditions, andcontrol actions that will be applied to operating the system. In thiscase, a microprocessor-based control offers the advantage of beingreprogrammable to provide different responses to different events andconditions. Unfortunately, the task of reprogramming is not easilyaccomplished by the typical person, since it generally requires theskills of a person who can program in assembly language. Even if apersonal computer is used as a control device, the interface used todefine the control scheme typically employs a high level language suchas BASIC, with which only a small percentage of potential users isproficient. Furthermore, errors in the logic employed in setting up thecontrol can creep in and remain undetected, with potentially harmfulresults.

The use of computers for controlling systems is well known, but in mostcases, the control programs employed are not adapted to handle changingenvironments. There are numerous instances wherein a personal computercontrol would be very welcome, if provided with an interface that peoplewithout specialized programming skills could use. For example, personalcomputers have been used for controlling appliances, lighting, andsecurity in residences. Since the required configuration and controlrequirement of a full home control can easily change with time, forexample, as new appliances and circuits are added or existing elementsare changed, it would be convenient if the user could readily adapt thecontrol scheme to handle such changes without reprogramming thecomputer.

Computer controls are not limited to applications such as total homecontrol. They can also be used in connection with hobbies, such ascontrolling toy vehicles running on a track. Many people investconsiderable time and money in building and operating model trainlayouts. These layouts are often complex, including many separate tracksections on which several trains run. Most often, the various trainsrunning on a layout are manually controlled. Several people may berequired to operate a complex system with several trains that arerunning to avoid collisions or overspeed on curves that can cause thelocomotive or cars to leave the track.

People involved in such hobbies enjoy trying to emulate circumstancesthat can arise in the operation of full-size vehicles. For example, justas actual trains run on schedules and over the same roadway or tracks asother vehicles, hobbyists enjoy scheduling and controlling the operationof the scale-size replicas of these vehicles. Computer control of thetoy vehicles provides an expedient method to schedule operation of thetoy vehicles, just as it does their full-size counterparts. However,control applications that enable non-programmers to easily defineschedules, events, conditions, and control actions in order toaccommodate changing control requirements are not presently available.

An effective computer control for toy vehicles running on a track musthave some feedback signal that provides information on the results of acontrol action. The same requirement applies to the control of othertypes of systems in which devices are controlled. If two model trains attimes share the same track layout, the control must be provided with asignal that denotes the location of each train and must use the signalto prevent a collision and possible derailment of the trains.

U.S. Pat. No. 4,349,196 discloses a computer controlled toy track systemin which an electro-optical sensing device disposed under the track orroadway senses the passage and identity of individual cars and producesa corresponding signal that is input to a microprocessor-based operatorcontrol panel. To identify specific cars, a strip bearing an appropriatebar code is attached underneath the cars, where it can be scanned by theelectro-optical sensing devices that are placed at predefined locationsin the layout. The control panel employed in this system is not that ofa personal computer, but instead, simply includes a keypad, a pluralityof light emitting diodes, and a one row alphanumeric display. Thissystem does not readily allow adaptation of the control to changingcircumstances and configurations. More importantly, its use requiresthat an existing system be retrofitted with the electro-optical sensors,which can be somewhat difficult to install and connect to the controlpanel.

Another aspect involved in the control of toy vehicles running on atrack relates to the way in which the speed of the vehicles iscontrolled. Low voltage alternating current (AC) can be applied to thetracks to provide power for the motors in the vehicles, but most modeltrain engines are powered by direct current (DC) motors. The speed ofthese motors is typically controlled by varying the voltage and polarityof the DC. Another method involves supplying the motors with a pulsewidth modulated (PWM) DC signal. The pulse width of this signal isadjusted to achieve a desired speed for the train running on a specifictrack section to which the signal is applied.

To independently control the motors in different locomotives suppliedwith power through the tracks, two approaches have been used. Asdisclosed in U.S. Pat. No. 4,341,982, a plurality of actuators generatea plurality of variably modulated selected frequencies that aresuperimposed on the DC power signal applied to the track. Receivers inthe locomotives of each different train running on the layout are eachtuned to a different selected modulated frequency. The variablemodulation signal is used by the receiver tuned to it to determine themotor speed of the locomotive in which the receiver is disposed.

Another approach uses pulse position modulation to control the motor ona specific engine. However, the circuitry required for this method isrelative expensive. Both of these prior art techniques for controllingspecific engines on a track layout require that each engine be modifiedto carry the circuitry needed to discriminate between the signalssupplied on the track in order to respond only to an intended speedcontrol signal. It would clearly be preferable to avoid modifying theengines in this manner and to simply directly couple the locomotivemotor to the DC power provided through the track on which the locomotiveis running.

SUMMARY OF THE INVENTION

In accordance with the present invention, a method for defining a finitestate machine to control a system includes the initial step of providinga graphic environment running on a computer, under which a controlapplication is run. While running the control application on thecomputer, a schedule manager grid that comprises the finite statemachine is graphically developed or defined by the user. The userselects symbols from among a plurality of different symbols representingcorresponding different possible events and associates the selectedsymbols with other symbols selected from among a plurality of differentsymbols representing possible control actions for the system. At leastsome of the different symbols represent events that can occur externalto the computer. Such external events are indicated by signals that areinput to the computer from the system being controlled. The selectedsymbols used to graphically define the schedule manager grid identify adesired control action that should occur when an event associated withthe desired control action occurs. Accordingly, a control signal thateffects the desired control action on the system when the eventassociated with said desired control action occurs is produced by thecomputer.

The plurality of different symbols from which symbols are selected alsoincludes symbols representing different conditions that can be satisfiedon the system. Preferably, when developing the schedule manager grid,the user also graphically selects a symbol that represents a desiredcondition and associates that selected symbol with the selected symbolsrepresenting the event and the desired control action. The step ofproducing the control signal then only occurs if the desired conditionis also met.

At least some of the plurality of different symbols preferably representevents that occur internally within the computer. The method furthercomprises the step of including a variable with at least one of theselected symbols representing the event, the desired condition, and thedesired control action in developing the schedule manager grid. Theschedule manager grid also preferably includes a plurality of lines ofselected symbols. Each line of selected symbols corresponds to a stateof the system in which is graphically indicated one of a plurality ofdesired control actions that should occur when one of a plurality ofevents occurs. The selected symbols respectively represent the desiredcontrol actions and the associated selected events.

Another aspect of the present invention is a system for controlling toyvehicles running on a track. This system includes a computer having adisplay screen, a central processing unit (CPU), an operator interface,a memory, and at least one port coupled to the CPU for input and outputof electrical signals. The CPU responds to electrical signals input tothe computer through the port in accordance with a state machine that isgraphically defined by an operator on the display screen using theoperator interface. The computer produces control signals that areconveyed through the port to control the toy vehicles. A power supplyproduces electrical power suitable to energize the toy vehicles. Thepower supply is coupled to a switching network that is controlled by theCPU in accord with the state machine defined by the operator. The systemalso includes a track that is divided into a plurality of sections. Eachsection of track is separately electrically coupled to the power supplythrough the switching network so that each section is independentlyenergized by the switching network under control of the CPU. A pluralityof toy vehicle detector circuits are included, each of which isassociated with a different one of the plurality of track sections.These detector circuits each monitor a detector signal on a differentone of the plurality of track sections. The presence of a toy vehicle onone of the plurality of track sections modifies the detection signal,which is produced by the switching network, causing the detector circuitmonitoring that track section to produce an output signal indicating thepresence of the toy vehicle on the track section.

Program instructions stored in the memory of the computer enable theuser to graphically define the state machine to control the plurality oftoy vehicles on the track. For at least one of the toy vehicles, thestate machine graphically identifies an event selected by the user andat least one control action selected by the operator for associationwith the event. The event at times comprises an arrival of one of thetoy vehicles on a selected section of track, as indicated by the changein the detection signal produced by the toy vehicle detection circuitassociated with that section of track. At other times, the controlaction comprises the CPU producing a control signal that causes theswitching network to energize a selected section of track when the eventhas occurred.

The program instructions enable the user to graphically define acondition that is associated with the event. The CPU does not producethe control signal to effect the control action associated with theevent until the condition(s) are satisfied.

Preferably, the switching network comprises a master control unit (MCU)that includes a plurality of motor control circuits. Each motor controlcircuit enables application of an electrical current produced by thepower supply to a specific section of the track in order to energize oneof the toy vehicles that arrives on that section of track. The trackincludes at least one electromagnetic switch that controls routing of atoy vehicle running over the electromagnetic switch, thereby controllingthe track sections over which the toy vehicle runs. The MCU selectivelyenergizes the electromagnetic switch in response to control signals fromthe computer. In addition, the switching network can comprise at leastone slave control unit (SCU). The SCU also includes a plurality of motorcontrol circuits, each of which enables application of an electricalcurrent produced by the power supply to a specific section of the trackin order to energize one of the toy vehicles that arrives on thatsection of track. The MCU and each SCU further comprise synchronizationmeans for ensuring that the motor control circuits, which controlelectrical current to adjacent sections of track, are synchronized toensure that the electrical current on one track section is in phase withthat on the adjacent track sections while a toy vehicle crosses aboundary between the adjacent track sections. This synchronizationprevents inadvertent speed changes by the vehicle when it crosses aboundary.

The switching network includes means for applying a detector pulse to asection of track, and the toy vehicle detection circuits respond to amagnitude of the detector pulse on one of the tracks comprising thesection of track to detect a toy vehicle on the section of track. Thepulse is conducted to the track section from the other track through anytoy vehicle that is disposed on the section of track monitored by one ofthe toy vehicle detection circuits. When the toy vehicle is not presenton the track section, there is no conduction between the tracks, and thepulse is not present on the track that is monitored. Periodically, theswitching network applies the detector pulse to the section of the trackwhen the switching network is not enabling the electrical current toenergize the toy vehicle. In one preferred form of the invention, theswitching network provides a PWM electrical current to energize the toyvehicle and controls the speed of the toy vehicle by controlling thewidth of pulses comprising the electrical current, in response tocontrol signals provided by the computer.

The program instructions executing in the computer enable the user tographically define the state machine by first selecting an event symbolfrom a plurality of predefined event symbols, each of which represents adifferent event that might occur. The user also may select a conditionsymbol from a plurality of predefined condition symbols, each of whichrepresents a different condition that must be satisfied. Finally, theuser selects an action symbol from a plurality of predefined actionsymbols, each of which represents a different control action that can beimplemented. In response to an event occurring represented by the eventsymbol selected by the user and a condition represented by the conditionsymbol selected by the operator being met, the program instructionscause the control action represented by the action symbol to beimplemented.

The plurality of condition symbols include a symbol indicating whether aspecific toy vehicle owns a section of track. A toy vehicle owns thesection of track if the toy vehicle can control that section of trackwithout interference from other toy vehicles, thereby ensuring that onlyone toy vehicle occupies that section of track at one time.

The CPU preferably includes a timer. If so, the plurality of eventsymbols include an event symbol that responds to expiration of a timeinterval on the timer.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a schematic block diagram showing a model railroad tracklayout and locomotives that are controlled by the present inventionusing a computer and a hardware interface to the track layout;

FIG. 2 is a schematic electrical diagram of an MCU that is used tocontrol a plurality of track sections and/or other electrical devices;

FIG. 3 is a schematic electrical diagram of an exemplary SCU that iscoupled to the MCU of FIG. 2 and used to control additional tracksections and/or other electrical devices on the track layout;

FIG. 3A is a schematic electrical diagram of a hand control unit (HCU)and a hand controller that enable manual control of a locomotive's speedand direction;

FIG. 3B is a schematic electrical diagram of the hand controller;

FIG. 4 is a schematic diagram of a track detection circuit used todetermine whether a train is on a specific section of track;

FIG. 5 is a graph showing a low-speed forward direction PWM drive signalinterleaved with a detection signal used to determine that a train is ona specific section of track;

FIG. 6 is a graph illustrating a higher-speed forward direction PWMdrive signal and the detection signal;

FIG. 7 is a graph showing a low-speed reverse direction PWM drive signaland the detection signal;

FIG. 8 is a graph showing an AC signal (for energizing accessories) thatis time multiplexed with the forward direction PWM drive signal and thedetection signal;

FIG. 9 is a graph showing an AC frequency shift keying (FSK) controlsignal (with a frequency that changes to represent a pattern of zeroesand ones to indicate the desired train speed) interleaved with adetection signal in accordance with the present invention;

FIG. 10 is a schematic block diagram illustrating the interface betweenthe virtual (computer) environment and the real world in which thepresent invention operates;

FIG. 11 illustrates an exemplary schedule manager grid used tographically schedule control actions that will be applied to thecontrolled toy train system in response to events occurring that meetdefined conditions;

FIG. 12 is an example of a control panel created by the user to enablemanual control of the train system by manipulation of the graphicalcontrols;

FIG. 13 is state diagram illustrating the control commands that can besent to the MCU, SCUs, and HCUs by the computer during reset, startup,and running of the control system;

FIG. 14 is a flow chart showing the overall control logic implemented insoftware in defining and operating the control system;

FIG. 15 is a flow chart illustrating the logical steps employed duringoperation of the schedule manager;

FIG. 16 is a flow chart that shows the logic employed in operating acontrol panel;

FIG. 17 is a flow chart illustrating the control steps among which auser can select in modifying the train control properties;

FIG. 18 is a flow chart of the logical step implemented during theinternal operation of the schedule manager;

FIG. 19 is a flow chart of the logic employed in configuring thehardware and start the asynchronous processes used by the hardware;

FIG. 20 illustrates the logical steps that occur as the user creates aschedule manager grid;

FIG. 21 is a flow chart showing the logical steps that are followed asthe user creates a control panel; and

FIG. 22 is a flow chart showing the logical steps involved in creating anew software configuration corresponding to the track layout.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT General Overview

In FIG. 1, an exemplary track layout 30 illustrates how the presentinvention is applied in a particular control application. While certainaspects of the present invention are intended for the control of toyvehicles on a track, or more specifically, control of model trains, itwill be appreciated that many other types of systems can be controlledwith the present invention. Software comprising a set of programinstructions runs on a computer 32 under a graphic user interface. Theseprogram instructions instruct the computer to control devices comprisinga system based upon a finite state machine that is visually andgraphically defined by the user. The finite state machine serves toestablish a list of rules by which the devices comprising the system arecontrolled in accordance with the program instructions. Thus, theprogram instructions enable a user to define state vectors for thedevices and then automatically control the devices as specified by thestate vectors. Optionally, the user can also manually control the systemby manipulating visual graphic representations of controls that cause acorresponding control action to be applied to the devices in the system.In the preferred embodiment, computer 32 runs the control software underthe Microsoft® WINDOWS™ graphics user interface; however, it iscontemplated that the control software can readily be adapted to run onother operating systems and other types of computers.

Description of Track Layout and Hardware

Track layout 30 is intentionally relatively simple in design, forpurposes of more clearly illustrating a specific application of thepresent invention, The track layout includes outer track sections 33,34, and 35 and inner track sections 36 and 37. A crossover track section38 couples inner track section 37 to outer track section 33. Crossovertrack section 38 is coupled to inner track section 36 through anelectromagnetic (track) switch 44 and to outer track section 34 throughan electromagnetic switch 46, enabling the software or the user toselectively route the locomotives 88 or 90 so that they cross betweenthe inner and outer track sections. A siding track section 40 is alsoprovided inside of the inner track section, and is coupled to innertrack section 36 through an electromagnetic switch 42. Whenelectromagnetic switches 42, 44, or 46 are electrically actuated, theycause locomotives 88 or 90 to travel onto siding track section 40 frominner track section 36, or onto crossover track section 38 from theinner track section or the outer track section, as the case may be.

Power in the form of PWM DC is separately selectively applied toexternal track sections 33, 34, and 35, internal track sections 36 and37, crossover track section 38, and siding track section 40, toselectively energize electrical motors (not shown) in locomotives 88 and90 when they are on one of those specific sections of track. The tracksections are electrically isolated from each other at the pointsindicated in FIG. 1 by the double hash marks crossing the track layout.Those who operate model trains will appreciate that the pair of rails ortracks (not separately shown) comprising each track section conveyelectrical current to the locomotive motors by conduction through thewheels and split axles. In addition to supplying power to thelocomotives, the track sections each are periodically energized withdetection pulses that are applied to one of the two tracks in each tracksection. Conduction of the detection pulses through the locomotivemotors enables the detection pulse to appear on the other track. Thepresence of the detection pulse on the other track is used to sense thepresence of a locomotive on any of the various track sections. Dataindicating the location of locomotives 88 and 90 on specific tracksections is provided to computer 32 for use in controlling thelocomotives.

To interface computer 32 to track layout 30 and to implement control andscheduling of locomotives 88 and 90, a switching network 49 is provided.The switching network selectively enables the flow of electrical currentto energize specific selected track sections and actuate specificselected electromagnetic switches, and determines the location of thelocomotives on specific track sections. In the preferred form of theinvention, switching network 49 includes at least one MCU 48 and mayoptionally include one or more SCUs 50, 52 and one (or more) HCUs 150.The SCUs allow additional track sections and electromagnetic switches tobe controlled, beyond the capacity of MCU 48, but are not be required incontrolling track layouts that have less than eight track sections andless than 16 electromagnetic switch circuits. HCU 150 allows manualcontrol (as opposed to directly manipulating the graphic user interfaceon computer 32) of the locomotives and electromagnetic switches by oneor more users, as will be explained below, and is therefore also notrequired for every installation. In the following discussion, thegeneric term "control units" is used in referring collectively to MCU48, SCUs 50 and 52, and HCU 150 or when there is no reason todistinguish between these devices.

A power supply 53 of generally conventional design provides DC to theMCU and to the SCUs and HCU 150 through lines 55, at appropriate voltagelevels and current capacity for energizing these devices and asappropriate to provide the power needed to control and operate thelocomotives and electromagnetic switches comprising track layout 30. TheSCUs and HCU are linked with MCU 48 in a token ring network 69 throughconductors 70, 72, 74, and 75. An RS-232 serial port (not separatelyshown) on computer 32 is coupled to MCU 48 through a line 68 and conveyscommands from the computer to token ring network 69 and data from thetoken ring network to the computer--all passing through MCU 48.

In the preferred embodiment, MCU 48 and SCUs 50, 52 are each able tocontrol PWM current to eight different track sections and to senselocomotives on the eight track sections. In addition, MCU 48 and each ofthe SCUs can control a plurality of electromagnetic switches. Since itwas intended that FIG. 1 not be overly complicated, fewer than themaximum number of track sections and electromagnetic switches that canbe controlled by each are shown coupled to MCU 48 and SCUs 50 and 52. Itwill be understood that additional SCUs can be added to the token ringnetwork to further expand the number of track sections andelectromagnetic switches that can be controlled thereby, so that anextremely complex model railroad layout (or other toy vehicle system)can readily be controlled, in comparison to relatively simple tracklayout 30. To emphasize that additional SCUs, up to some arbitrarynumber "n," can be added, SCU 50 is labeled "SCU₁ " and SCU 52 islabeled "SCU_(n) " in FIG. 1.

In the preferred embodiment, MCU 48 is coupled to electromagnetic switch42 through a line 58 and controls the switch by selectively supplyingthe DC needed to actuate it so that it changes state, i.e., moves fromone position to another. In addition, the MCU enables power to besupplied to external track section 34 and to crossover track section 38through lines 60 and 62, respectively, where each such line comprises apair of conductors, each of which is separately coupled to one of thetwo parallel tracks comprising each section of track. Detection signalsalso supplied through these same lines are used to detect the presenceof one of the locomotives on these track sections, as explained below.SCU 50 enables power to be supplied to and detects the presence oflocomotives on siding track section 40 and inner track sections 36 and37 through lines 64, 65, and 66, respectively. Likewise, SCU 52 iscoupled to electromagnetic switches 44 and 46 through lines 56 and 54,respectively, for controlling their operation, and enables power to besupplied to and detects the presence of locomotives on outer tracksections 33 and 35. HCU 150 is not directly coupled to any tracksection, but instead generates control signals to which computer 32responds; the computer issues corresponding commands to the MCU and SCUsthat cause power to be enabled to the track sections on which aparticular locomotive is disposed in accordance with the control signalsproduced by the HCU.

Although the software running on computer 32 enables an operator toschedule the operation of locomotives 88 and 90 running on track layout30 in an automated fashion, based upon timed events and otherestablished conditions corresponding to state vectors comprising thefinite state machine defined by the user, the system also permits manualcontrol of the speed, braking, and direction in which the locomotivestravel in response to the user manipulating a hand controller 152. Handcontroller 152 is coupled through a line 92 to HCU 150. Although thepreferred embodiment illustrates only a single hand controller, it willbe apparent that HCU 150 can be coupled to a plurality of handcontrollers (up to eight in the preferred embodiment), enabling acorresponding plurality of different users to each control a differentlocomotive running on the track layout. It is important to note that HCU150 is not hardware coupled to any specific track sections. Instead,each hand controller 152 is dynamically configured by the user tocontrol a specific locomotive by passing commands from computer 32 tothe MCU and SCUs, so that the locomotive assigned to the hand controlleris controlled regardless of the track sections on which the locomotiveis running.

Computer 32 in the preferred embodiment is generally conventional,including a CPU 76 (represented by the computer console), and a keyboard78. A floppy disk 80 is included for initial input of the softwareprogram files, which are run as a WINDOWS™ application on CPU 76. Inresponse to the machine instructions comprising the software programfiles, computer 32 provides display screens that accept user input todefine a schedule and operate the locomotives and track layout inaccordance with the user input. Computer 32 also includes a displaymonitor 86, and a hard drive (not separately shown), which is used tomore permanently store the software program files and to store otherfiles created while running the software program. In addition tohandling input through keyboard 78, the user interface employs a mouse82. The mouse is coupled to CPU 76 through a line 84, which is connectedto one of the RS-232 serial ports on the computer or to a separate businterface (not shown), as is conventional. A user can move the mouse,causing a cursor to move in corresponding fashion on the display monitorscreen, and using the mouse buttons, can select items on the displaymonitor and move them about, as is generally conventional in othergraphic user interface application programs. Although computer 32 isillustrated as a desktop unit, it will be appreciated that a relativelysmaller notebook size computer can also be used.

Turning now to FIG. 2, details of MCU 48 are shown in a block diagram.An RS-232 interface circuit 102 is connected to the RS-232 serial porton the computer through a transmit line 68a and a receive line 68b.RS-232 interface circuit 102 is in turn coupled to a microprocessor 100through a line 104, which provides input of commands to themicroprocessor from computer 32; in addition, line 104 is coupled to aline 70a through which commands are passed on to each of the othercontrol units on token ring network 69. Data from microprocessor 100 andfrom the other control units on token ring network 69 are suppliedthrough a line 106 to RS-232 interface circuit 102 and thus, to computer32. During startup of the control system, computer 32 first configuresMCU 48 and then each of the other control units, one at a time,assigning each a unique address. The MCU initially takes ownership of atoken that determines which control unit controls the token ringnetwork, and after the MCU has been configured, passes the token to thenext control unit on the token ring network. Since only the control unitcurrently in possession of the token can respond to commands duringstartup, addresses are assigned in an orderly fashion to each controlunit on the token ring network in succession. Once an address isassigned to one of the control units, only that control unit responds tocommands from computer 32 that are directed to that address, i.e., afterthis configuration process has been completed during startup, therespective control units each only respond to commands directed to theirassigned address. Since line 106 is shared by MCU 48 and each of theother SCUs and HCUs in the system to pass data back to the computer, itcan only be used by the device that currently has the token. The tokenis passed from MCU 48 to SCU 50 when microprocessor 100 briefly dropsthe normally high token port signal conveyed on a line 70b to a lowlevel, i.e., produces a negative pulse. The token is passed in thismanner around all of the control units and thus, returns to MCU 48 fromHCU 150 on a line 75b, which is coupled to an interrupt port ofmicroprocessor 100.

Firmware embedded in microprocessor 100 of MCU 48 is used to control theMCU. For example, microprocessor 100 generates a sync pulse thatsynchronizes all of the SCUs and HCUs on the token ring network, andthis sync pulse is conveyed on a line 70c to all of the control units.The sync pulse determines when all of the devices enable detector pulsesfor detecting the presence of a locomotive on a specific track sectionand ensures that motor control pulses (explained below) on adjacenttrack sections are in sync with each other so that as a train crosses aboundary between two track sections controlled by different SCUs, thetrain does not exhibit a short surge of speed, by ensuring that the PWMdrive signals applied to adjacent sections of track are in phase. In thepreferred embodiment, the synchronization pulse frequency is about 120Hz.

A plurality of pairs of lines 110 and 112 couple output ports onmicroprocessor 100 with a corresponding plurality of motor controlcircuits 108. Specifically, lines 110a and 112a are coupled to a motorcontrol circuit 108a, lines 110b and 112b are coupled to a motor controlcircuit 108b, etc. In addition, two enable lines 114a and 114b arecoupled to each motor control circuit 108 from microprocessor 100 in MCU48. Either a logic level 1 or logic level 0 can appear on the enablelines, but a logic level 1 on both enable lines is required to enableoutput current to a given track section (or other type of load)controlled by MCU 48 from motor controls 108 supplied over lines 118aand 118b. If both lines 114a and 114b convey a logic level of 0, nocurrent flows in lines 118a and 118b, and the output impedance betweenthe lines is high to prevent shorting of the detection pulse when thePWM driving current signal is not being applied. The polarity of theoutput current conveyed to track sections 116a through 116h from motorcontrols 108 depends upon the logic levels on pairs of lines 110 and112. When line 110 is high and line 112 is low, current flows in onedirection through lines 118a and 118b, and when line 110 is low and line112 is high, it flows in the opposite direction.

In addition to conveying current to energize track sections 116 (orother loads attached thereto), lines 118a convey a detector pulse toeach of track sections 116a through 116h. If a load is coupled to lines118a and 118b on a given track section, e.g., if one of the locomotivesis present on the track section, the detector pulse is conducted throughthe load and into line 118b for that track section. Lines 118b arecoupled to detector circuits 126, which in turn, are coupled throughlines 128 to input ports of microprocessor 100. Thus, microprocessor 100in MCU 48 is able to sense the presence of a train on a particular tracksection, based upon presence of the detector pulse on line 118b that iscoupled to that track section. Further details of detector circuits 126are described below.

Table 1, which follows below, summarizes the relationship between thelogic levels on lines 110, 114, and 112 and the effect on each motorcontrol 108.

                  TABLE 1                                                         ______________________________________                                        CONDITION OF                                                                              LOGIC LEVELS    OUTPUT                                            MOTOR       PRESENT ON LINES                                                                              LEVEL                                             CONTROL     110    112    114a 114b 118a   118b                               ______________________________________                                        Forward     1      0      1    1    H      L                                  Reverse     0      1      1    1    L      H                                  Detection   1      X      1    0    PULSE  HI-Z                               ______________________________________                                    

In the above table, "X" represents a logic level that can be either 0 or1, H is the higher voltage side of the drive signal, L is the lowervoltage side, "PULSE" represents the detection pulse, and "HI-Z" is theimpedance on the terminal of the motor control coupled to line 118bwhile the detection pulse is output on line 118a. This high impedance onthe terminal of the motor control prevents the detection pulse that isconducted through a vehicle setting on the tracks from being shorted toground within the motor control, thereby enabling the pulse on line 118bto be sensed and the locomotive on the track to be detected.

To control the electromagnetic switches, such as electromagneticswitches 142a and 142b, a serial output port on microprocessor 100 iscoupled through a line 134 to a shift register 130. Shift register 130is clocked by a clock signal provided by the microprocessor through aline 132. Shift register 130 is a serial-in, parallel-out shift registerthat is loaded serially by the microprocessor each time that anyelectromagnetic switch controlled by the MCU is required to changestate, e.g., to move right or left. The shift register produces enablesignals that are input in parallel via lines 136 to opto-couplers 138.Lines 139 convey the optically isolated signals to Darlington arrays141. In response to these enable signals, the Darlington arrays producea signal that changes the state of one or more of electromagneticswitches 142. These signals are conveyed to electromagnetic switches 142lines 140. Although only one electromagnetic switch 142 is shown, itwill be understood that up to 16 such switches can be controlled by MCU48.

An array of configuration switches 144 are coupled to microprocessor 100through lines 146. These configuration switches are digi-switches thatare used to assert logic levels on input ports of the microprocessor todetermine, for example, whether microprocessor 100 is the microprocessorin MCU 48, or alternatively, in one of the SCUs, and to indicate whetherthe switching network includes any SCUs or HCUs, so that the token ringnetwork functions should be enabled. Other functions of microprocessor100 can also be selectively controlled by appropriately settingconfiguration switches 144.

In FIG. 3, a schematic block diagram for SCU 50 is illustrated, which isexemplary of the configuration of each of the SCUs used in the controlsystem of the present invention. Since SCU 50 and each of the other SCUsinclude virtually the same components as MCU 48, the same referencenumerals have been used to identify the elements of SCU 50 that are incommon with those of MCU 48. The only significant differences betweenthe configuration of the MCU and that of the SCUs arise in the settingof configuration switches 144, as noted above, and with regard toconnecting its microprocessor 100 into the token ring network. Line 70aconveys commands to microprocessor 100 of SCU 50, and a line 72a conveysthese commands onto the next SCU in the token ring network. Line 70bcarries an interrupt signal that was produced by MCU to pass the tokento SCU 50. When SCU 50 passes the token to the next control unit in thetoken ring network, it generates a short negative pulse on its tokenport, which is coupled to a line 72b. The sync pulse from MCU 48 isinput on a line 70c and conveyed to the next SCU through a line 72c. Inall other respects, the components of each of the SCUs operate asdescribed above.

Details of HCU 150 are shown in FIG. 3A. When HCU 150 has the token,data are output from microprocessor 100 in the HCU over line 106, whichis also coupled to the data lines of the other SCUs and MCU. Inaddition, commands are conveyed from the computer to the microprocessorin the HCU from the preceding control unit over a line 74a, and onto MCU48 (in the preferred embodiment) over a line 75a. An interrupt isreceived via a line 74b from the preceding SCU in the token ring networkto pass the token to the HCU, and HCU 150 passes the token to MCU 48 byproducing a short negative going pulse on the token port of itsmicroprocessor. The token port on microprocessor 100 of the HCU iscoupled to a jumper 73 into a line 75b back to the interrupt port of MCU48. Sync pulses generated by the MCU are input to microprocessor 100over line 70c, and would be conveyed to the next control unit in thetoken ring network if any were provided.

An enable port on microprocessor 100 of HCU 150 is coupled through aline 156 to an address decoder 154. Address decoder 154 can selectivelyaddress one of eight possible hand controllers 152, only one of which isshown in FIG. 3A. Addresses output on lines 158 determine which of thehand controllers are selected to provide input control data to HCU 150or to receive data from the HCU at any given time. The output lines ofaddress decoder 154 are each connected to a different AND gate 161 (onlyone shown) through lines 159. The other input to each AND gate 161 is aclock signal produced by microprocessor 100 that is conveyed on a line160. The output of AND gate 161 is conveyed through a line 162 to aclock input on a shift register 164 in hand controller 152. Serial dataoutput from microprocessor 100 in HCU 150 are conveyed on a line 166 toshift register 164 in each of the hand controllers. The shift registerconverts the serial data into corresponding parallel data for output tolight emitting diodes (LEDs) 168a, 168b, and 168c, which arerespectively red, green, and yellow in color. The color of the LED thatis lighted provides the user with a feedback indication from the controlsystem that shows the status of the train being controlled. When thenext section of track is occupied by another train, the red LED islighted; the green LED indicates that the train is free to move onto thenext section of track; and, the yellow LED is lighted if the section oftrack just beyond the next section is occupied by another train. Thestatus of each of these LEDs is determined by one-bit output from shiftregister 164, based upon data input from microprocessor 100 in HCU 150.The enable signal input on line 156 to address decoder 154 determineswhether the clock signal is applied to shift register 164 to reset thestate of LEDs 168.

The clock signal on line 160 is also coupled to the clock input of aparallel-in, serial-out shift register 186. Each of the eight parallelinputs to shift register 186 comprises a bit from a direction switch 182in one of the hand controllers. In response to the clocking signal inputto shift register 186, a serial data stream is produced on the output ofthe shift register, which is coupled to an input port of themicroprocessor in the hand controller through a line 188. This serialdata stream comprises bits that indicate the status of the directionswitches in each of the hand controllers. Direction switch 182 simplyprovides a logic level 1 or 0 in each hand controller to indicate thedirection selected, which is input to microprocessor 100 in HCU 150.

Addresses are also provided over lines 158 to an analog-to-digitalconverter (ADC) 174, having eight analog inputs, each of which iscoupled by lines 172 to a speed control 170 in a different handcontroller. In response to the address input to ADC 174, one of the handcontrollers is selected for processing, i.e., the analog voltagedeveloped by the speed control in a selected hand controller isconverted to a corresponding digital value, which is input to a port ofmicroprocessor 100 in HCU 150 over lines 176.

A schematic circuit for speed control 170 is shown in FIG. 3B. Speedcontrol 170 includes both a throttle control 178 and a brake switch 180.In the speed control, a line 172b is coupled to one terminal of brakeswitch 180, which is a single-pole, double-throw type switch, and isalso coupled to one side of a capacitor 190, the opposite side of whichis coupled to ground through a line 172c. Capacitor 190 suppressestransients when brake switch 180 is operated. When brake switch 180 isnot depressed, the switch toggle is coupled to the V⁺ supply voltage.The toggle terminal on brake switch 180 connects to one end of avariable potentiometer (throttle control 178), and the other end of thevariable potentiometer is coupled to one end of a resistor 177. Theother end of the resistor is connected to circuit ground through line172c. An analog voltage developed by setting the wiper of throttlecontrol 178 is input to ADC 174. Resistor 177 serves to provide aminimum (non-zero) analog voltage on line 172a, when throttle control178 is at its minimum resistance position, thereby enablingmicroprocessor 100 in HCU 150 to distinguish between a minimum throttlesetting, which corresponds to the voltage developed across resistor 177and the zero analog voltage that results when brake switch 180 istoggled to the ground terminal on line 172c.

MCU 48 and each of the SCUs include detector circuits 126. Details ofthe detector circuit for a single track section or other load imposed onone of motor controls 108 are shown in FIG. 4. It will be understoodthat each track section is coupled to a corresponding detection circuitlike detection circuit 126a. Detection circuit 126a includes an inverter148a having an input that is connected to line 118b; the output ofinverter 148a is conveyed through a line 128a to the microprocessorinput port. Line 118a extends directly from motor control 108a to tracksection 116a. When motor control 108a produces a detector pulse on line118a, any load such as the electric motor of one of the locomotives,which is electrically connected between lines 118a and 118b (i.e.,between the rails of track section 116a to which these lines arecoupled), will conduct the detector pulse from the track connected toline 118a to the other track that is connected to line 118b. Thedetector pulse only appears on line 118b when a load is present on thetrack section to which the specific lines 118 are connected. Inverter148a inverts the logic level of the detector pulse on line 118b,producing a corresponding inverted logic level on line 128a that isinput to the microprocessor of the MCU or SCU. If no locomotive ispresent on track section 116a, the detector pulse does not appear online 118b. The detector pulse on line 118b inverted to a logic level 0indicates to microprocessor 100 in the MCU or SCU that a train orlocomotive is present on track section 116a. Conversely, if a locomotiveis not present, the 0 logic level on line 118b is inverted to a logiclevel 1. The high impedance of the motor control terminal connected toline 118b during the time that the detection pulse is generated preventsthe pulse from being shorted to ground. The detector circuits coupled toeach of the other track sections being monitored by the MCU or SCUoperate in an identical manner.

In order to better understand how the detector pulse is integrated withthe drive pulses that energize an electric motor in one of thelocomotives on the same lines 118, it is helpful to refer to FIG. 5. MCU48 and each of the SCUs comprising the switching network are programmedto produce driving pulses 202 having a rising edge occurring apredefined time interval after each synchronization pulse 206. This timeinterval allows a detector pulse 204 to be produced between successivedriving pulses 202. Each time that synchronization pulse 206 is receivedby microprocessor 100 in the SCUs (generated by the microprocessor inthe MCU), it causes the microprocessor to disable the logic level onlines 110 for each of the motor control circuits 108, to producedetector pulses 204 on lines 118a, and to set the impedance of the motorcontrol circuit terminals coupled to lines 118b high. If a train ispresent on a specific one of the track sections 116 at the time that thedetector pulse is sent over lines 118a, the detector pulse causes thecorresponding detector circuit 126 to produce a logic level 1 outputsignal indicating to the microprocessor (and thus to computer 32) that atrain is present on that track section. Thereafter, until the nextsynchronization pulse 206, microprocessor 100 enables motor controlcircuits 108 (both track section output circuits) using the two logiclevels input on lines 114a and 114b in response to commands receivedfrom computer 32. (See Table 1 above.) During this time, driving pulsesprovided to track sections 116 over lines 118a and 118b are selectivelyPWM by microprocessor 100 to generate a pulse of current for a portionof the time interval between synchronization pulses 206. The duration orpulse width of these PWM drive pulses depends upon the speed desired forthe train on the specific track section to which the drive pulse issupplied. In FIG. 5, driving pulses 202 are relatively short inproportion to the total time interval between synchronization pulses 206and extend between 0 and V⁺ volts. Accordingly, any locomotive on thetrack section supplied with driving pulses 202 would run at a relativelylow speed, in the forward direction.

In comparison, FIG. 6 shows a graph 208 in which a substantially longerduration driving pulse 210 is provided during the period between each ofthe synchronization pulses 206. Accordingly, a locomotive energized withdriving pulses 210 would run at a relatively higher speed than ifenergized with driving pulses 202 (in FIG. 5).

When it is desired that the locomotive move in the reverse direction,driving pulses 214 having a negative polarity are provided, as shown ingraph 212 of FIG. 7. Thus, since driving pulses 214 are of substantiallythe same width or duration as driving pulses 202 in FIG. 5, thelocomotive would respond by running in reverse at a relatively slowspeed. Note, however, that regardless of the direction in which thelocomotive is driven, detector pulses 204 continue to have a positivepolarity.

It may sometimes be desirable to inject an AC signal from motor controlcircuits 108 onto track sections 116 in addition to the PWM drive pulsesand detector pulses discussed above. The AC signal can be used toenergize accessories, such as train lights. Since the AC signal has arelatively high frequency compared to the PWM drive pulses, the averagezero value of the AC signal does not affect DC (or PWM) actuatedcomponents, such as the locomotive motors. However, the AC voltage isonly injected during a portion of the period before each of thesynchronization pulses, as shown in FIG. 8. In graph 216, AC signal 218is periodically injected between driving pulses 220 and synchronizationpulse 206. A detector pulse 204 is still provided alter eachsynchronization pulse, before the driving pulse. As in FIG. 5, theproportion of the drive period (up to the next synchronization pulse)when a non-zero voltage is applied to the track section depends upon thedesired speed. For low speeds, the drive pulse is narrow or shorter induration, and for high speeds, the drive pulse extends for the entireportion of the cycle available to each drive pulse. In FIG. 5, thevoltage is zero during the period between the end of one drive pulse 202and the synchronization pulse 206, but in the scheme illustrated in FIG.8, this period of time is filled with AC signal 218, enabling theaccessories, which are energized by both the drive pulse and the ACsignal to remain fully active. Consequently, if a train is stopped ormoving relatively slowly due to a short duration drive pulse beingapplied to the locomotive motor, the train lights will still remain atfull brightness.

Although the preferred embodiment disclosed above uses a DC PWM signalto energize the locomotive motors, alternatively, locomotives can beprovided that are energized using an AC signal on lines 118a and 118b.By modulating the frequency of this AC signal to indicate a series oflogical 1's and/or 0's using a FSK technique, commands can betransmitted to detector circuits in the train locomotives. In a graph222 in FIG. 9, a repeated bit pattern (1101101) is transmitted as an ACsignal 224. The FSK modulated AC signal uses a high frequency toindicate a logic level 1 and a low frequency to indicate a logic level0. This type of scheme is like that currently being adopted as a DigitalCommand Control (DCC) Standard by the National Model RailroadAssociation (NMRA). In this scheme, trains contain electronic circuitrythat decodes the bit patterns conveyed by the AC signal as data packets.The motors of the locomotives are not directly electrically coupled tothe track; instead, the power to drive the motors is drawn from thetrack by rectifying the AC signal within the train to provide a DCsignal that powers the motors in the train locomotives. The speed of themotors and thus, of the trains, is controlled in response to the datapackets conveyed by the AC signal.

In the prior art DCC control scheme, a control causes a transmitter tosend FSK modulated data packets over the entire track. There are noseparately energized track sections that are electrically isolated fromeach other in the prior art model train layout. The FSK modulatedcommands coupled to the prior art track layout include an address sothat each locomotive or train running on the track layout is separatelyand selectively controlled in response to the modulated AC signalpresent throughout all of the track. Each of the trains running on thelayout only responds to the data packet commands addressed to it. Thedisadvantage of this prior art approach is that there is no way todetect where each train is located on the track, unless one of the priorart schemes discussed above in the Background of the Invention is used.For example, a plurality of opto-electronic detectors could be installedat different points on the track layout to detect trains at or passingthose points.

The present invention can be used for scheduling and control oflocomotives and trains running on model train layouts employing the DCCscheme just described and has several advantages over the prior artapproach that arise due in part to the division of track layout 30, forexample, into the plurality of electrical isolated track sections shownin FIG. 1. As shown, in this embodiment, each of the track sections issupplied with an FSK modulated AC driving signal and a detection pulsethrough the separate pairs of lines that couple the control units to thedifferent track sections. (As already noted, there can be a plurality ofdifferent track sections in each of the inner and outer loops and thelayout can be much more complex than that shown in FIG. 1.) Yet, unlikethe prior art scheme, detector pulse 204 is applied to each tracksection in the present invention along with the FSK modulated ACsignals, as shown in FIG. 9, to enable a train or locomotive to beeasily detected on any of the different track sections.

By generating the required FSK modulated AC signals with motor controlcircuits 108 under the control of computer 32, the DCC speed controldata packets can be separately provided to each of the track sections.Since each of the track sections are electrically isolated from eachother, if desired, the DCC drive signal can be applied to only thosetrack sections on which a train that responds to the DCC packet data isrunning. Other track sections can be supplied with the non-digital PWMdrive signal to control more conventional trains or locomotives, asdiscussed above. This type of hybrid embodiment that provides control ofthe DCC type trains with PWM driven trains is not possible under theprior art, but is in connection with the present invention.

Description of Software

Referring to FIG. 10, an overview diagram 230 illustrates therelationship between hardware and software in connection with theapplication of the present invention to the control of locomotivesrunning on track layout 30, but the Figure is intended to more generallyrepresent the invention so as to assist the reader in appreciating howit can be applied to many other applications. A curved line 232represents the hardware interface responsible for communicating betweena user 238, and MCU 48 and each of the SCUs described above inconnection with the control of locomotives 88 and 90 and of otheraspects of track layout 30 (shown in FIG. 1). This hardware interfaceinteracts with the software and is coupled to the control units throughthe RS-232 serial port of computer 32, as described above. On the leftside of hardware interface 232 in the Figure, functional aspects of thesoftware include an event system 240 (or finite state machine) that isdefined by user 238, who is part of the real world and therefore appearson the right side of the line represented by hardware interface 232. Thevirtual (computer) world represented by the software controlling tracklayout 30 and locomotives 88 and 90 in the preferred embodiment existson the left side of the line.

Event system 240 includes two distinct parts, the first comprising aschedule manager 242, which reacts to state vectors comprising a programgrid 244, and implements the control functions of a dispatcher 258. Inresponse to events and conditions listed in the grid, the schedulemanager carries out associated actions 266 that are also defined in thegrid. Events are supported by an abstraction wherein each event 254 isan instance of a class created by an event source 246 that is passed toevent sink 256 to be handled by dispatcher 258. Each event class has astandard set of behaviors and properties that allow it to be treateduniformly by the event system, and a set of unique properties reflectingthe semantics of an actual event. Typically, event sources are developedby the hardware interface, for example, as a result of the hardwaredetecting a train arriving on a particular track section, or in responseto internal components of the software system, such as the lapse of atimer interval. The detection of a train or locomotive on a particulartrack section uses hardware resources 250 (such as detection circuits126), which generate a real event 248. In connection with such hardwareresources, the software continually monitors the condition of sensors,such as the detector circuits, as provided in a box 262, to determine ifa predefined real event has occurred or if a condition 260 has been met.Similarly, in connection with software resources 252 (such as a softwaretimer), a box 264 provides for continually checking to determine if apredefined virtual condition has been met. In response to the occurrenceof events arriving from event sink 256 at dispatcher 258, a controlaction may be implemented by schedule manager 242 as defined by grid244. These actions may modify software resources 252 or hardwareresources 250, for example, by energizing one of the train locomotivesto move to a different track section or by resetting a software timer.In addition, hardware resources, such as hand controller 268, can affectsoftware resources 252, since manipulation of the hand controller by theuser can cause a concomitant change in corresponding graphical control.

User 238, who exists in the real world, also interacts with the virtualworld through control panels 270, which include track controls andelectromagnetic switch controls. Thus, user 238 can employ the softwareand controllers to implement actions 266, thereby affecting either thesoftware resources and/or hardware resources.

Hardware interface 232 enables computer 32 to communicate with theswitching network comprising the control units used to control a system,which in the preferred embodiment disclosed above includes thecomponents of track layout 30 and the locomotives running on the tracklayout. The hardware interface is divided into three elements, includinga configuration and diagnostic command interface, a control commandinterface, and the event interface. The configuration and diagnosticinterface is used to send commands to the MCU and SCUs during startup,to synchronize the switching network with the computer. For example,commands are sent by computer 32 during the initial configuration tolearn the nature of the attached control units and to assign addressesto each for subsequent use when it is necessary for the computer toroute commands to these devices. In addition, the configuration anddiagnostic interface can query the state of the control units andinstruct each control unit to perform on-board diagnostic tests and toreport the results to computer 32.

The command interface is used after system configuration is completed,to send commands to the control units comprising the system. Forexample, as explained below, the user can graphically control thecomputer so that it sets the speed of trains running on particular tracksections and selectively changes the status of any of electromagneticswitches 42, 44, and 46.

Finally, the event interface provides real-time status information abouteach device or element that is controlled to computer 32. The eventinterface is normally asynchronous, so that events can arrive atcomputer 32 at any time. In the preferred embodiment disclosed herein,the status of one of the control units is communicated to the softwareapplication running on computer 32 any time that a change occurs at thatcontrol unit. In this preferred embodiment, two types of status changesare handled, including detection of trains entering or leaving tracksections, and changes made on hand controllers that set the speed of atrain. However, it will be appreciated that virtually any type ofmeaningful real-world change or event, which can be sensed, can bemonitored to inform the control software of a change of status. In thepresent control system, such status changes are routed as events to thecontrol software for use by the schedule manager. Preferably, hardwareinterfaces that handle events are associated with corresponding eventsource modules. In the example discussed above, detector circuits 126comprise a hardware interface for handling the event represented by thearrival of a train on a particular track section to which acorresponding track section detector module in the software responds.

Schedule manager 242 graphically supports an abstraction to clearlydefine how attached hardware should be controlled. Specifically, theschedule manager provides a user interface that enables user 238 tocreate, view, and edit schedule manager grids. An exemplary schedulemanager grid 280 is illustrated in FIG. 11. Schedule manager grid 280,which has many of the attributes of any conventional graphic userinterface window, such as vertical and horizontal scroll bars andbuttons that allow the window to be resized, also includes a menu bar282 and a button bar 284 and comprises a plurality of rows 288a through288h, each row representing a state vector. It will be understood thatmany more rows can be included and accessed by scrolling down to bringthe additional rows into view. A column 290 includes row numbers thatsequentially increase. In addition, schedule manager grid 280 comprisesa plurality of columns 292a through 292i (shown in the windowrepresented by FIG. 11), but again, it will be appreciated thatadditional columns may be included that are accessed by scrolling to theright, to bring the additional columns into view.

In the schedule manager grid, column 292a specifies an event for each ofthe rows or state vectors comprising the schedule manager grid. Eachevent in column 292a is followed by any conditions that are to apply inthe state vector (i.e., by zero or more conditions), each conditionoccupying an additional column element in the row. Following theconditions in each row (if any) are one or more elements that contain agraphic specification for an action to be taken when the event occurs,if any conditions imposed have been met.

A user defines the schedule manager grid row-by-row, by selecting aparticular element in the button bar or menu bar that displays a groupof graphic icons representing events, conditions, or actions. From thedisplayed group of icons, one of the icons is selected using the cursorand mouse 82 and then dragged to the desired row and column position inthe schedule manager grid. The drag-and-drop technique employed to thuscreate elements of each row in the schedule manager grid is well knownto those of ordinary skill in the art in connection with other graphicuser interface software applications, and need not be further discussedat this point. It is sufficient to note that graphic icons representingeach of the possible events, conditions, and actions to be taken areselectively displayed by the software to enable a user to definevirtually any kind of control abstraction for a particular devicecontrolled by the software. For example, the control of the locomotives,the status of the electromagnetic switches, and the operation ofvirtually any other electrically actuated accessory associated withtrack layout 30 can be controlled and scheduled in any way desired bythe user. In addition to selecting the graphic icons that representevents, conditions (if any), and control actions desired, the user canalso specify variables, such as speed, or time intervals that will applyto an associated event, condition, or control action.

Details of the control parameters represented by several exemplarygraphic icons shown in schedule manager grid 280 will help to clarifysome of the control options available to the user when defining thestate vectors corresponding to the rows of the schedule manager grid. Anevent icon 294 having a "GO" label indicates that the followingcorresponding control action in the row should be implemented when theschedule manager grid is activated. An icon 298a in the row indicatesthat a train 4 should "take possession of" or "own" a track 4. (Notethat "train 4" and "track 4" and other such references in schedulemanager grid 280 are arbitrary examples and do not correspond to anytrack section or locomotive on track layout 30 in FIG. 1.) The terms"take possession of" or "own" indicate that the train has the exclusiveright to be present on the designated track section. It will be apparentthat the safe control of a plurality of trains on a track layoutrequires that only one train or locomotive at a time be present on agiven track section, thereby avoiding the possibility of collisions andensuring that each train or locomotive is separately controlled.Conversely, an icon 298b in row 288c and column 292b with its associateddescriptive text " 4->6" indicates that train 4 does not have possessionof or own track 6 (the tilde denotes the negative condition).

A timer icon 308 with the associated variable "4[5]" indicates that atimer 4 is to be set for a five-second countdown. The events,conditions, and control action defining one vector state are assembledin a row by the user to achieve a desired result. For example, an icon300 with the associated text variable "6" in row 288d indicates that theevent corresponds to any train arriving on track 6. The next twoelements of row 288d are conditions that must be met. Specifically,train 4 must own or have possession of track 6, and track 3 must not beowned by any train. If the event and conditions are met, the controlactions represented by the graphic icons in columns 292e and 292f of row288d set the speed for the train running on track 3 to 20 and assignownership of track 3 to train 4. Other actions that can be implementedinclude changing the status of a switch, as represented by an icon 306in row 288b and column 292h, which shows a switch 3 being moved to aleft position. Further, an icon 310 (column 292a, row 288h), which is adifferent color than icon 300, indicates that a train has left track 6.Events, conditions, and control actions are evaluated row by row, fromtop to bottom of the schedule manager grid. The graphic icons discussedabove are examples of various types of events, conditions, and actionsthat can be combined to define a schedule manager grid, but many othericons representing other events, conditions, and control actions can beprovided. For application of the present invention to the control ofother types of systems, event, condition, and action icons appropriateto the application and system being controlled would be provided.Accordingly, it should be evident that the schedule grid managerrepresents a form of a finite state machine that is used to controlvirtually any type of devices in a system.

The software underlying the schedule manager must provide support forthe following functions: (a) creating or defining an element in theschedule manager grid; (b) performing a specified condition check underthe control of dispatcher 258; and, (c) implementing a control actionwhen called upon by the dispatcher. In addition, the software mustprovide a mechanism for dispatcher 258 to identify events in theschedule manager grid that match an event that has occurred either inthe virtual world or the real world.

Events, conditions, and actions tend to be implementation dependent orapplication specific, being dictated primarily by the attached hardwareand type of system being controlled. However, certain types of events,conditions, and actions would likely be provided regardless of thehardware or type of system being controlled, because of their generalapplicability to virtually any control paradigm. Those control eventsthat are implementation dependent include actions that must beimplemented so as to map onto a full set of control commands that can besent through the hardware interface to the attached hardware elements.In the preferred embodiment that is discussed above, such actions arethose associated with the control of devices on the track layout andlocomotives running thereon. For example, the elements of the schedulemanager grid will include events responding to a track becoming occupiedor a track becoming unoccupied, and conditions such as a track beingoccupied or unoccupied, or an electromagnetic switch being set in somemanner (for example, right, left, or straight to control the tracksection to which a train will be directed), or a locomotive speed anddirection, set in a predefined manner. The implementation specificactions include setting speed and direction for a locomotive running ona track section, setting an electromagnetic switch to a defined state,and dealing with changes in train speed that take into consideration themomentum of the locomotive and the attached cars. Ideally, the softwareshould react to the rate at which a train running on a particular tracksection attains a new speed or slows so as to accurately emulate thebehavior of a real locomotive, in the scale of the track layout.Computer 32 handles such functions transparently by sending successivespeed commands through the token ring network to the MCUs and SCUs tochange the speed of a selected train in a series of steps. The mass andother characteristics of the locomotives and other cars in the trainsbeing controlled can therefore be input as user supplied variables, toensure faithfully realistic control of the trains.

More generally, these three types of schedule manager gridelements--events, conditions, and actions, which are implementationspecific, include such things as activation and deactivation events andcorresponding actions. For example, when a schedule manager grid isactivated, at least some of the rows can be associated with the eventrepresented by its activation, which is useful for setting up an initialstate of the system being controlled. Similarly, when a schedule managergrid is deactivated, that very deactivation can be associated withcertain rows, just as any other event is, and such rows can be executedjust before the schedule manager grid becomes deactivated. Thus, forpurposes of controlling the flow of control actions, a specifiedschedule manager grid can activate another schedule manager grid, or,alternatively, deactivate itself or another schedule manager grid.

Another generalized type of element is a set of software timers, whichoperate as real time clocks. In the preferred embodiment, each schedulemanager grid has a fixed number of timers at its disposal. In addition,a set of global timers is provided. Actions using the timers includesetting a timer to start timing at a specified future time anddeactivating a current timer before the time it will time out. Inaddition, an event can be associated with the expiration of a timeinterval determined by a timer so that the schedule manager waits for aspecified period of time before taking a defined control action.

A key aspect of the present invention relates to "ownership events,conditions, and actions" noted above in connection with a train owning atrack section. The concept of ownership allows the schedule manager totake control of a global resource (virtual or real) before trying toperform any actions upon it. Such resources are typically physicalentities in the hardware system being controlled, such as tracksections, although they need not be in other implementations. In thepreferred embodiment disclosed above, the schedule manager adheres to aprotocol that requires ownership of a track section by a train beforeany attempt is made to control it, for example, by setting a speed of alocomotive running on it. For this reason, it is appropriate for eachschedule manager grid to be associated with a specific train that isfollowing a route designated by the schedule manager grid, so that theschedule manager successively assigns exclusive ownership of tracksections along the designated route to the train before advancing thetrain over each track section. In the event that the next track sectionneeded to advance a first train is owned by a second train operated by adifferent schedule manager, the first train is made to wait, as if itwere at a stop signal.

In connection with the ownership of a specific resource, certain events,conditions, and actions are provided, independent of the resources thatare owned. For an action to be taken, ownership of the resource withwhich the action is associated must have been granted. The dispatcherdetermines which schedule manager grid gains access to such events whenthey occur. For conditions, a resource can be: owned by the devicecontrolled by the schedule manager grid, not owned by it, free of anyownership, or owned by a device controlled by another schedule managergrid that is not specified. Actions associated with ownership include:requesting ownership of a resource by the schedule manager, and freeinga resource for ownership by another device controlled by a differentschedule manager grid. One of the reasons that ownership is so importantin the present control scheme is that the schedule manager grids useheuristic means to prevent interactions between themselves; for example,to prevent collisions between trains that are being operated accordingto different schedule manager grids. Failure to follow these principlescan result in trains colliding because they are attempting to operate onthe same track. In the preferred embodiment, owners are indicated witharbitrary numbers that are available for use globally. Although it issometimes convenient to associate a schedule manager grid with thecontrol of only one train, this convenience is not enforced in thecontrol scheme.

It should be apparent that when the present invention is used in othercontrol applications, the concept of resource ownership may be totallyunimportant. Accordingly, it is contemplated that the requirement forownership be relaxed or completely ignored when the present invention isapplied to controlling resources in such applications where ownership isnot critical.

Dispatcher 258 is responsible for activating and deactivating schedulemanager grids, routing events to the appropriate active schedule managergrid, and calling condition and action elements in a row in which eventshave occurred. To enable a user to properly specify the events,conditions, and actions comprising rows or state vectors of a schedulemanager grid, the user must be able to predict the behavior of thesystem being controlled and, thus, to design the schedule manager gridso that the dispatcher performs the preceding tasks in a well-definedmanner. For example, the user must be aware that the dispatcher willsearch through the active schedule manager grids in the order in whichthey are activated any time that an event occurs. Thus, when an eventhappens, the first activated schedule manager grid is searched beforesubsequently activated schedule manager grids. Secondly, the user mustknow that within a specific schedule manager grid, the dispatchercompares the event that has just occurred with the events in the firstcolumn of each of the rows in the schedule manager grid, starting at thetop and working toward the bottom. The first row or adjacent multiplerows in which the event that has just occurred matches the eventspecified are then activated. For example, in FIG. 11, the event in rows288d and 288e corresponding to the arrival of any train on track section6 will trigger activation of those two rows. The actual comparisonbetween an event that has just occurred and the events specified in agiven schedule manager grid is not a function of the dispatcher.Instead, the dispatcher simply passes an event to the eventimplementation portion of the schedule manager, which then performs thecomparison. As a result, all sorts of complexity are possible,including, for example, enabling an ownership event to maintain aprivate list of control actions that are waiting for a resource tobecome free, and only matching the event with an event in the listassociated with a control action having the highest priority. Third, theuser must know that if a schedule manager grid has multiple rows withevent icons corresponding to an event that has just occurred, the eventis dispatched by the dispatcher to each row in turn, moving from top tobottom. Finally, the dispatcher follows a protocol wherein within agiven row, the conditions, and then the actions, are checked andimplemented from left to right.

As just explained, the schedule manager grids allow a user to define aseries of scheduled or automated control actions using events andconditions to determine when or if the control actions are implemented.However, the present invention also includes a visual graphic userinterface that enables a user to have direct manual control over thesystem. In the preferred embodiment, the user can directly manipulategraphic controls to set the speed of trains running on selected tracksections and set the status of selected electromagnetic switches intrack layout 30. To facilitate such graphically implemented manualcontrol, the software allows the user to create graphic control panels.An exemplary graphic control panel 320 is shown in FIG. 12. Such controlpanels are free-form windows onto which a user places control iconscorresponding to real world hardware elements using the drag-and-droptechnique discussed above, in connection with the creation of theschedule manager grids. These graphic representations of such real worldelements are then manipulated by the user (with the cursor and mouse),causing a corresponding change in the status of the real world devices.Graphic manipulation of the icons and symbols representing such realworld elements are convened into control signals by computer 32 and areoutput as commands to the MCUs and SCUs so that corresponding controlactions are taken by the real world elements.

In FIG. 12, a control panel 320 includes a menu bar 322 and a button bar324 in a format generally consistent with other windows of the graphicuser interface used in the preferred embodiment. Control panel 320includes graphic icon representations of 20 different electromagneticswitches 326, showing their current status. It should be noted that the20 electromagnetic switches do not correspond to the switches in tracklayout 30, but are simply included by way of illustration to show howthe electromagnetic switches in a more complex train layout could begraphically represented in control panel 320.

In addition, a graphic speed control 328 is included in control panel320 and is manipulated by the user selecting a slider 332 using thecursor and then moving the slider with the cursor, in the mannercustomarily used in graphic user interfaces of this type. The user movesthe slider graphically to actually change the speed of a train on theassociated track sections controlled by the graphic speed control. Thespeed thus selected by the user is indicated digitally in a small window334 below slider 332 on speed control 328, with a range between ±31 inthe preferred embodiment. To set the speed in the reverse direction, theuser holds the Shift key on the computer keyboard while adjusting slider332 with the cursor and mouse. A brake button 333 is graphicallyactuated to slow the train while the user depresses the mouse selectbutton with the cursor on the brake button.

Each speed control is associated with an HCU selected from a drop-downwindow 335, which are arbitrarily designated "A," "B," "C," etc. A setof "signal lights" 331 selectively display red, yellow, or green basedupon the status of the train controlled by the graphic controller, i.e.,green if it is free to run on the next track section, yellow if thetrack section after the next is occupied by another train, and red ifthe next track section is occupied.

The graphic control is associated with specific track sections asdesignated by the user when setting up control panel 320 and with aspecific train running on the track sections that is also determined bythe user. To enable the user to make these selections, a dialog box 321opens over the control panel window. The dialog box includes a list ofavailable track sections 323 from which the user can select with thecursor and mouse those to be controlled by the graphic control, causingthem to appear in a list of assigned track sections 325. A label for thetrain running over these track sections that is controlled by thegraphic control can be entered in text box 327. Another box 329 isprovided to enable the user to select a relative virtual mass of thetrain (light, medium, or heavy) that affects the "momentum" or rate atwhich the train accelerates or brakes in response to user actuation ofthe graphic control.

Since operation of control panel 320 by a user may interfere withsettings that are being controlled automatically by the schedulemanager, a user would normally not manually manipulate graphic controlscorresponding to devices that are currently being automaticallycontrolled. The software can optionally be set by the user so that theautomatic control of the schedule manager overrides the manual control,for example, to avoid the manual control causing a collision between twotrains.

FIG. 13 is a state diagram 340 illustrating the control protocol forcommunications between computer 32 and the control units. During aninitial startup 342 of the control system, all control units are unableto respond to any other command besides "Reset Controllers," asindicated in a block 348. This command causes the control units toexamine their configuration switches and prevents spurious interruptsfrom affecting the operation of the control system. Next, all controlunits are configured during setup, as indicated in a circle 344. Thevalid commands during setup are listed in a block 350 and include thecommand for setting the address to each control unit in succession.After the address is set for a control unit, the control unit ignoresall further configuration commands except "Reset Controllers," therebyenabling a mask program to be used as addresses are assigned during thesetup. After the setup is completed, the control system begins running,as indicated in a circle 346. The valid commands that can be issuedwhile the control system is running are listed in a block 352. Certaincommands are valid to the MCU and SCUs and other are specific to theHCU. A hard reset (e.g., power off followed by power on) returns thecontrol system to the startup state. Similarly, if a "Reset Controllers"command is issued, the system returns to the setup state.

A flow chart 360 in FIG. 14 generally shows the logical stepsimplemented in the control system software for configuring the softwareand hardware, and for developing the schedule manager grids that defineautomated control of the system. The process starts in a block 362 whenthe control software program is initiated and proceeds to a block 364that provides for configuring the hardware and starting the asynchronousprocesses. The steps carried out in block 364 are presented in a flowchart 500, which is shown in FIG. 19. From a start block 502, the firststep in a block 504 is to reset the hardware, which involves providing areset signal for microprocessors 100 in each of the control units.Thereafter, in a block 506, computer 32 assigns addresses to eachsuccessive control unit in the system, as the token is passed from onecontrol unit to another in the token ring network. Next, in a block 508,track section detector reception is enabled so that the software can beinformed of the track sections on which trains are disposed. In a moregeneralized sense, i.e., for use in other control applications, block508 would involve enabling any sensors or monitors in the system beingcontrolled. A block 510 provides for starting hand controller receptionso that the system can immediately respond to throttle, braking, anddirection input signals from any of the hand controllers coupled to HCU150. The hardware configuration and asynchronous process startupterminate in a block 512, returning logical control back to flow chart360 in FIG. 14.

A decision block 366 then determines whether the software has beenconfigured for the system being controlled. If not, a block 368initiates the steps required for creating the software configuration.The logical steps involved in creating a new software configuration areshown in flow chart 560 in FIG. 22. From a start block 562, a decisionblock 564 determines if the various track sections and switchescomprising different track circuits in model layout 30 have beenconfigured. If they have, a block 566 selects logical track sectionnumbers that are assigned to each track section in the layout. (Thesetrack section numbers correspond to the "track numbers" referenced inconnection with exemplary schedule manager grid 280 in FIG. 11.) Then ablock 568 identifies the control unit that is associated with thevarious track circuits, i.e., the control unit that controls the PWMdrive pulses applied to each track section, for the track circuits inthe track layout. The logic then proceeds to a decision block 570 thatdetermines if the track circuit configuration has been completed. Ifnot, the logic returns to decision block 564 to continue with theconfiguration of the track circuits.

If decision block 564 determines that the track sections and switcheshave not been configures, in a block 574, the logic provides forselecting a logical switch number for each of the electromagneticswitches. In addition, a block 576 identifies the switch type for eachelectromagnetic switch identified by the number selected in thepreceding block. Board and circuit numbers are selected and assigned toeach electromagnetic switch of a particular track circuit in a block578. Thereafter, decision block 570 determines if the track circuitconfiguration is completed and, if so, proceeds to a block 572 that endsthe process.

Returning back to FIG. 14, if the software has previously beenconfigured and stored as a file, a block 374 provides for loading aselected software configuration file. Once a previously defined softwareconfiguration file is loaded, the user has the option of modifying thesoftware configuration in a block 376. Modification of the softwareconfiguration might be needed if the track layout has been changed byadding additional electromagnetic switches or changing track circuits orif the user has modified the way in which the electromagnetic switchesand track sections are coupled to the control units. A user can alsooptionally modify the software configuration that was just created inblock 368.

A decision block 372 checks to determine if the software and hardwareconfigurations match. In other words, the control program determines ifall track sections have been assigned to the control of specific controlunits in a logical fashion. If not, the user is warned in a block 378.If the software and hardware configurations do match, the user mayselect one of five possible options.

The first option, which is indicated in a block 380, enables the user tocreate a new schedule manager grid. The logical steps implemented inthis option are shown in a flow chart 516 in FIG. 20. From a start block518, the user creates an empty schedule manager grid in a block 520.Starting at the first row of the empty schedule manager grid, as notedin a block 522, and in a block 524, the user selects an eventcorresponding to one of the graphic icons in button bar 284 on theschedule manager window. Then, the user optionally selects the condition(if any), as indicated in a block 526, and identifies actions that areto be carried out once an event happens and any conditions selected bythe user are met, as noted in a block 528. A schedule manager grid mayhave only a single row, but more typically has a number of rows.Therefore, a decision block 530 determines if the user is interested increating more rows or state vectors for the schedule manager grid. Ifso, a block 532 advances to the next row and returns the flow of logicto block 524 so that the user can select an event, any conditions, andone or more actions for the next row of the schedule manager grid usingthe graphic drag-and-drop technique discussed above, or alternatively,by selecting menu items that correspond to a desired event, condition,or control action. The user may also provide variables such as speed ortime, which are associated with one or more of these elements. Once theschedule manager grid is completed, the logic proceeds to an end block534. Returning to FIG. 14 and following decision block 372, anotheroption that the user has is to load the schedule manager, as indicatedin a block 382. This step presumes that at least one schedule managergrid has already been created and possibly stored as a file on the harddrive or on a floppy disk for access by computer 32.

A block 386 provides the user the option of creating a graphic controlpanel. As noted above, the graphic control panel enables the user tographically manipulate a graphic control that causes a correspondingchange in a device on the system being controlled. In addition, if handcontroller 152 is employed in the system, any manual manipulation of thethrottle, brake button, and/or direction switch on hand controller 152is reflected in a corresponding change in the graphic controls on thecontrol panel created by the user.

The steps involved in creating a control panel are illustrated in a flowchart 540 in FIG. 21. From a start block 542, the user creates an emptycontrol panel window in a block 544. Next, in a block 546, the userselects the specific graphic control icons that will be added to thecontrol panel, such as speed control icons or electromagnetic switchicons, as discussed above in connection with exemplary control panel320. Using mouse 82 to control the cursor, the user selects the controljust added to the window for the control panel and positions it in adesired location within the control panel window in a block 548. Oncethe graphic control icon has been selected and properly positioned, ablock 550 provides for the user setting the control properties, such asindicating the particular track section(s) or train with which thecontrol icon is associated, the mass of the locomotives and cars in thetrain, and the current condition of an electromagnetic switch. Adecision block 552 determines if the user desires to create additionalgraphic controls in the control panel and, if so, returns to block 546to repeat the steps discussed above. Otherwise, the flow of logic forcreating the control panel ends in a block 554.

Once a control panel has been created by the user (block 386), it can bestored as a file and thereafter, as noted in a block 384 (FIG. 14),optionally loaded from the stored file, which is maintained on a floppydisk or in the hard drive of computer 32. However, if a user is notinterested in creating a schedule manager grid, loading a previouslycreated schedule manager grid, or in creating a control panel or loadinga previously created control panel, the user may instead exit theprogram, as indicated in a block 388.

After a schedule manager grid has been created, or once it has beenloaded from a stored file, the user also has the option of modifying itas indicated in a block 390. Such modifications might be used to changethe times that the trains are scheduled to run on certain track sectionsor modifying the route of a train. Similarly, the control panels thathave previously been created or are loaded from a file can be modified,as indicated in a block 392. The user also has the option of closing acontrol panel, as provided in a block 394, or closing a schedule managergrid as indicated in a block 396. Alternatively, the user may againelect to exit the software control program in a block 398.

A fourth option that most often would be selected by the user is tocontinue to operate the schedule manager in accordance with a block 400,or to operate the graphic control panel in accordance with a block 402.At any time, the user can switch between the schedule manager window andthe control panel window, or may elect to exit the program, as providedin a block 404.

The logical events involved in operating the schedule manager grid aredisclosed in FIG. 15, in connection with a flow chart 410. From a startblock 412, the user activates the schedule manager in a block 414,typically by selecting an icon in a window of the graphic userenvironment. Once the schedule manager is activated, it proceeds tohandle any events that may occur, as noted in a block 416.

The logical steps implemented in handling events are shown in a flowchart 464 in FIG. 18. The occurrence of an event initiates an interruptto which the software responds. Accordingly, a block 466 suggests thatthe logic is interrupt driven and simply waits for an event to occur.Such events may comprise an external event, as noted in a block 468,such as the arrival of a locomotive on a particular track section, or aninternal event, as provided in a block 470. An example of an internalevent would be a software timer completing its preset time interval.Once either of these two types of events occurs, as noted in a block472, the schedule manager begins reviewing each of the schedule managergrids that are open and active, as indicated in a block 474. At times,only a single schedule manager grid may be active; however, morecommonly, for complex systems, a plurality of schedule manager grids areactive at any one time. Starting with the first row of the firstschedule manager grid, as stated in a block 476, the schedule managerdetermines if that row is handling this event. In other words, if theevent that has just occurred appears as a corresponding graphic icon inthe first column of that row in the schedule manager grid, the row ishandling the event as indicated in a decision block 478. If not, thelogic proceeds to a decision block 480, which determines if anyadditional rows exist in the schedule manager grid and, if so, proceedsto a block 490. Block 490 provides for advancing to the next row. Thelogic thereafter returns to decision block 478. If no other rows existin the schedule manager grid, a decision block 492 determines if thereare any additional schedule manager grids to be checked in connectionwith the event that has just occurred. If not, the logic proceeds backto block 466 to wait for the next event. Otherwise, it advances to checkthe next schedule manager grid, as noted in a block 494, and then startsreviewing the first row in that schedule manager grid in accordance withblock 476.

Once an event graphic icon is found in a row of the schedule managergrid being checked that matches the event that has just occurred (block478), a block 482 provides for evaluating the conditions in that row (ifany). A decision block 484 determines if all of the conditions aresatisfied and, if not, proceeds to decision block 480 to check otherrows in the schedule manager grid being reviewed. However, if allconditions are satisfied, the logic proceeds to a block 486, whichexecutes each of the control actions appearing in the row for which amatching event and all satisfied conditions have been found. The resultof executing the action typically involves a hardware action, such asadvancing a train from one track section to another or changing anelectromagnetic switch status. Therefore, a block 488 sends theappropriate command to implement the actions to be executed to thehardware via the control unit that is handling the device to becontrolled. The logic then proceeds with decision block 480 to evaluateany other rows in which matching events and all satisfied conditions mayexist. Once all rows in the schedule manager grid currently beingreviewed are evaluated, the schedule manager checks the next activeschedule manager grid to identify and respond to any other matchingevents in a similar fashion.

Returning to FIG. 15, the user may at any time decide to proceed to ablock 418, which provides for deactivating the schedule manager.Subsequently, the logic terminates in a block 420. Once the user hasdeactivated the schedule manager, the user may then decide to againactivate the schedule manager, as per block 414.

In FIG. 14, if the user elects to operate the control panel, inaccordance with a block 402, the logic carries out steps that areillustrated in FIG. 16 in a flow chart 424. Beginning at a block 426,the logic offers the user the option of selectively controlling one ofthe electromagnetic switches, in accordance with a block 428, or ofselectively controlling one of the trains, by providing the appropriatedriving signals to a locomotive, as indicated in a block 430. If theuser decides to operate one of the electromagnetic switches, he/she thenhas the option of operating a graphic control in a block 432, orchanging a logical switch number associated with an actual hardwareswitch, as provided in a block 434.

If the user decides to operate one of the graphic switch controls on thecontrol panel, any change made by the user results in a command beingsent by computer 32 to the electromagnetic switch corresponding to thegraphic control. This command is sent through the MCU or SCU that iscoupled to control that electromagnetic switch, as indicated in a block444 and causes the status of the electromagnetic switch to change.

Alternatively, if the user decides to control the speed of a train usingthe control panel, he/she can either elect to modify the properties ofthe graphic control for the train in connection with a block 436, or tooperate one of the graphic speed controls on the control panel, asprovided in a block 438. After completion of any selected option inblocks 432, 434, 436, or 438, the logic can proceed to an end block 446or can provide for further selection of these options. Should the userchoose to operate one of the graphic speed controls, any action taken,for example, moving the slider on the graphic control, results in acorresponding command being sent to the MCU or SCU that is coupled tothe corresponding track sections on the route over which the train isrunning. This command causes the control unit to change the width of thedrive pulses supplied to the specific track sections associated with thegraphic control, which has the effect of changing the speed of the trainthat is on those track sections, as indicated in a block 442. It shouldalso be noted that instead of operating a graphic control to achievecontrol over a train on a particular track section, the user canalternatively operate hand controller 152, selectively changing thethrottle position, or direction of the train, or activating the brakebutton, as indicated in a block 440. In response to manual manipulationof the hand controller, any corresponding graphic control in the controlpanel visually changes and the appropriate command is sent to theswitching network by computer 32.

Block 436 enables the user to selectively modify properties of thecontrol panel. The logical steps implemented in carrying out thisselection appear in a flow chart 450 in FIG. 17. After a start block452, the user is given the choice of changing the hand controllernumbers associated with the graphic controls in the control panel in ablock 454, or changing logical track section numbers with which thegraphic controls in the control panel are associated in a block 456.Alternatively, the operator can, as indicated in a block 458, setproperties of the train, such as its relative virtual mass (light,medium, or heavy), name or label, number of cars attached, etc. Afterany one of the possible choices represented by blocks 454, 456, or 458are selected by the user, the logic proceeds to an end block 460. Thelogic then returns to the main flow chart shown in FIG. 14, giving theuser the range of options already discussed for running and modifyingthe control system.

While the present invention has been disclosed in connection withcontrolling a plurality of locomotives running on a track layout, itwill be appreciated that other applications of the invention can readilybe implemented with only appropriate changes to the hardware andsoftware. In fact, other types of toys, such as race cars running on atrack can be controlled with virtually no change in the software andhardware elements disclosed above. It is also contemplated that theoverall control scheme can be adapted for use in controlling any type ofsystem in which devices are electrically actuated in response to events.Thus, the control scheme can be used in connection with controlling anentire house, for switching lights on and off at designated times, andfor controlling security and fire detection, manipulating entertainmentdevices such as stereos and televisions, and generally controlling anydevice plugged into an electrical outlet. The control scheme of thisinvention is ideally suited to many types of business applications. Forexample, the control scheme could be used in making decisions concerningthe buying and selling of stock (the control action), based upon eventsand conditions relating to stock prices, other parameters of thecompanies represented by the stock shares, and changes in stock indexes.Another application for which this control scheme is well suited is thecontrol of theatrical lighting, special effects, and other actions thatmight need to be implemented during a stage presentation or concert. Thegraphic interface of the present invention enables the user to easilydevelop complex control schemes in which a variety of events,conditions, and actions are defined. Accordingly, the invention is seento have utility far beyond the exemplary use in controlling toy vehiclesrunning on a track discussed above.

While the present invention has been disclosed in connection with apreferred embodiment and modifications thereto, it is not intended thatthe scope of the invention in any way be limited by this disclosure.Instead, the scope should be determined entirely by reference to theclaims that follow.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. A system for controllingtoy vehicles running on a track, comprising:(a) a computer including adisplay, a central processing unit, an operator interface, a memory, andat least one port coupled to the central processing unit for input andoutput of electrical signals, said central processing unit responding toelectrical signals input to the computer through said at least one portin accordance with a state machine that is graphically defined by a userwith the operator interface, by producing control signals that areconveyed through said at least one port to control the toy vehicles; (b)a power supply producing electrical power suitable to energize the toyvehicles, said power supply being coupled to a switching network that iscontrolled by the central processing unit in accord with the statemachine defined by the operator; (c) a track divided into a plurality ofsections, each section being separately electrically coupled to thepower supply through the switching network so that each section isindependently energized by the switching network under control of thecentral processing unit; (d) a plurality of toy vehicle detectioncircuits, each associated with a different one of the plurality ofsections of track to detect a toy vehicle that is disposed on saidsection of track; and (e) program instructions stored in the memory,said programmed instructions enabling the user to graphically define thestate machine to control the plurality of toy vehicles on the track,said state machine graphically identifying for at least one of the toyvehicles an event selected by the user, and at least one control actionselected by the user for association with the event, said event at timescomprising an arrival of one of the toy vehicles on a selected sectionof track as detected by the toy vehicle detection circuit associatedwith that section of track, and said control action at times comprisingthe central processing unit producing a control signal through said atleast one port that causes the switching network to energize a selectedsection of track when said event has occurred.
 2. The system of claim 1,wherein the program instructions enable the user to graphically defineat least one condition that is associated with the event, the centralprocessing unit not producing the control signal to effect the controlaction associated with the event until said at least one condition issatisfied.
 3. The system of claim 1, wherein the switching networkcomprises a master control unit that includes a plurality of motorcontrol circuits, each motor control circuit enabling application of anelectrical current produced by the power supply to a specific section ofthe track in order to energize one of the toy vehicles that arrives onthat section of track.
 4. The system of claim 3, wherein the trackincludes at least one electromagnetic switch that controls routingbetween sections of the track of a toy vehicle running over theelectromagnetic switch, and wherein the master control unit selectivelyenergizes the electromagnetic switch in response to control signals fromthe computer.
 5. The system of claim 3, wherein the switching networkcomprises at least one slave control unit, said slave control unitincluding a plurality of motor control circuits, each motor controlcircuit enabling application of an electrical current produced by thepower supply to a specific section of the track in order to energize oneof the toy vehicles that arrives on that section of track.
 6. The systemof claim 5, wherein the master control unit and each slave control unitfurther comprise synchronization means for ensuring that the electricalcurrent on one track section is in phase with that on adjacent tracksections while a toy vehicle crosses a boundary between the adjacenttrack sections, to prevent inadvertent speed changes by the toy vehiclewhen it crosses the boundary.
 7. The system of claim 1, wherein thetrack sections each comprise pairs of rails, the switching networkincludes means for applying a detector pulse to one rail of the pair ofrails comprising a section of track, and the toy vehicle detectioncircuits respond to a presence of the detector pulse on the other railof the pair of rails comprising the section of track, the detector pulsebeing present on said other rail as a result of electrical conduction ofthe detector pulse through the toy vehicle from the one rail to theother rail.
 8. The system of claim 7, wherein the switching networkperiodically applies the detector pulse to the section of the trackwhile the switching network is not enabling electrical current todrivingly energize the toy vehicle.
 9. The system of claim 7, whereinthe switching network provides a pulse width modulated electricalcurrent to energize the toy vehicle and controls the speed of the toyvehicle by controlling the width of pulses comprising said electricalcurrent in response to control signals from the computer.
 10. The systemof claim 2, wherein the program instructions enable the user tographically define the state machine by:(a) selecting an event symbolfrom a plurality of predefined event symbols, each of which represents adifferent event that might occur; (b) selecting a condition symbol froma plurality of predefined condition symbols, each of which represents adifferent condition that must be satisfied; and (c) selecting an actionsymbol from a plurality of predefined action symbols, each of whichrepresents a different control action that can be implemented.
 11. Thesystem of claim 10, wherein the program instructions further enable theuser to graphically define the state machine by associating the eventsymbol selected with at least one condition symbol that was selected andat least one action symbol that was selected, to define one of a row anda column in a schedule manager grid comprising at least said one of therow and column, said schedule manager grid to be used for controlling atleast one of the toy vehicles.
 12. The system of claim 11, wherein inresponse to an event represented by the event symbol selected by theoperator occurring and a condition represented by the condition symbolselected by the operator being met, the program instructions cause thecontrol action represented by the action symbol to be implemented. 13.The system of claim 12, wherein the plurality of condition symbolsinclude a symbol indicating whether a specific toy vehicle owns asection of track, the specific toy vehicle owning the section of trackif said specific toy vehicle can control that section of track withoutinterference from other toy vehicles, thereby ensuring that only one toyvehicle occupies said section of track at one time.
 14. The system ofclaim 12, wherein the central processing unit includes a timer, andwherein the plurality of event symbols include an event symbol thatresponds to expiration of a time interval on the timer.
 15. The systemof claim 1, wherein the switching network produces frequency modulatedalternating current signals that are supplied to the track sections inresponse to control signals from the computer, said frequency modulatedalternating current signals conveying commands defined by changes infrequency to the toy vehicles running on the plurality of track sectionsto indicate a desired speed and direction of the toy vehicles.
 16. Thesystem of claim 15, wherein the frequency modulated alternating currentis supplied only to selected track sections by the switching network inresponse to control signals produced by the computer.
 17. The system ofclaim 15, wherein the switching network produces detector pulses thatare periodically interspersed with the frequency modulated alternatingcurrent signals, said toy vehicle detection circuits responding to aconductance of the detector pulses through the toy vehicles to determineif one of the toy vehicles is present on a specific track section.